Telephonic Interview on July 23, 2007 



Applicant appreciates the time that Examiner took to conduct a telephonic interview with 
the undersigned on July 23, 2007. Also present during the telephonic interview was Karl Ginter, 
who is a technical consultant of the assignee. During the interview, the following two related 
applications were discussed -- 10/086,602 and 10/086,268. 

No exhibits were shown nor were any demonstrations conducted. No particular claims 
were discussed. However, the feature of an "enterprise directory" in the claims, including the 
enterprise directory being "a directory of named objects, including users, network devices and 
network services" was discussed. 

The specific prior art that was discussed includes U.S. Patent 6,909,708 to Krishnaswamy 
et al. and assigned (on its face) to MCI Communications Corporation. 

No proposed amendments were discussed. 

The principal argument of the Applicant is that the "database" disclosed by the 
Krishnaswamy patent does not anticipate the "enterprise directory" feature recited in the claims. 
The Examiner argued that Applicant's specification does not distinguish between a "database" 
and an "enterprise directory" and that, therefore, the Examiner is free to apply the "database" of 
Krishnaswamy against the "enterprise directory" recited in the claims. 

No agreement was reached during the interview. 

REMARKS 

Statutory Subject Matter 

The Examiner contends that claim 20 is directed to a data structure of a database that 
does not fall within any of the four categories of statutory subject matter. Applicant respectfully 
traverses the rejection. 

In particular, claim 20 is directed to an article of manufacture. Furthermore, the 
"enterprise directory" (not a database, as discussed below with respect to the prior art based 
rejections) embodied thereon produces functional advantages that disappear if the same data is 
recorded in a different format. According to the In Re Lowry case and cases following it, this is 
sufficient to distinguish a claimed invention from what might otherwise be considered 
unpatentable "printed matter." More particularly, that the enterprise directory embodied on the 
article of manufacture produces functional advantages that disappear if the same data is recorded 
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in a different format indicates that the claimed format has a functional significance that can be 
separated from its data recording contents. 

Examples of such functional significance pervade Applicant's specification. For 
example, see paragraph [0086] of the published version of Applicant's specification, which 
discusses: 

[0086] In a preferred embodiment, the enterprise directory 90 is implemented using a 
general purpose directory such as NDS. The invention introduces schema extensions in 
NDS. The schema extensions enhance the NDS base schema so that it supports the 
Directory Services requirements for an H.323 Recommendation based IP telephony 
network. In addition to H.323 support, the schema extension enables the H.323 
gatekeepers in an H.323 IP telephony network to automatically find each other. This 
capability is not currently specified and supported by the ITU H.323 Recommendation 
v.l. The schema extensions also enable the invention to provide many of its unique 
features, e.g. caller ID, follow me with call filtering, etc. 

Since the claimed format has a functional significance that can be separated from its data 

recording contents, claim 20 recites patentable subject matter under 35 USC 101. 

Indefiniteness 

Claims 28 and 38 are rejected as being indefinite, due to the use of a trademark. Claim 
28 has been cancelled. Claim 38 had been amended to remove the portion reciting the 
trademarks. 

Prior Art Based Rejections 

It is noted that the Krishnaswamy patent is either the sole reference or a primary 
reference in the prior art based rejections. In using the Krishnaswamy patent to reject the claims, 
the Examiner is contending that Krishnaswamy' s disclosure of a "database" anticipates the 
"enterprise directory" feature in Applicant's claims. Note that the Examiner does not contend 
that Krishnaswamy ' s disclosure of a database renders obvious the "enterprise directory" feature 
in Applicant's claims. For example, in rejecting claims 21, 27 and 29-31 of the '602 application 
as anticipated under 35 U.S.C. 102(e) 1 , the Examiner notes in part (see page 3 of Office Action, 
in Item 6): 



1 It is noted that 35 USC 102(e) is not applicable in any event. Applicant is treating this rejection as if a rejection 
under 35 USC 102(a). 
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. . . and an enterprise directory server (Fig. 19F, Directory is enterprise directory server or 
Fig. 10A, Ref 1, 2, 3) coupled to the plurality of gateway networks, the enterprise 
directory server comprising an enterprise directory that is a directory of named objects, 
including users, network devices and network services and having an extensible schema 
configured to provide data to support routing of telephone calls (Fig. 10B, Ref enterprise 
Directory server 1082, user profile, telephone gateway and email address etc. and Fig. 
10A,Refl-3). 

As mentioned above in the Examiner Interview Summary, the Examiner has argued that 
Applicant's specification does not distinguish between a "database" and an "enterprise directory" 
and that, therefore, the Examiner is free to apply the "database" of Krishnaswamy against the 
"enterprise directory" recited in the claims. 

It is respectfully submitted that there is no such requirement for Applicant' s specification 
to distinguish between a "database" and an "enterprise directory." If this was the case, then 
applicants would be required to predict every rejection an Examiner may present and provide 
rebuttal distinguishing language in the specification, even before the patent application has been 
filed. Clearly, this cannot be the requirement. 

Thus, Applicant once again respectfully submits that the "database" of Krishnaswamy 
does not anticipate the "enterprise directory" recited in the claims. It is respectfully submitted 
that it is the Examiner who has the initial burden to demonstrate that each and every element as 
set forth in the claim is found, either expressly or inherently described, in a single prior art 
reference. Here, the Examiner has not demonstrated that the Krishnaswamy "database" 
anticipates the "enterprise directory" recited in the claims. It is respectfully submitted that the 
anticipation rejection is improper for at least this reason alone. 

However, even though it is not Applicant's burden to do so, in the interest of furthering 
prosecution and supplementing the record, Applicant provides herewith evidence that the 
Krishnaswamy "database" does not anticipate the "enterprise directory" recited in the claims. 
Applicant does this by way of providing several references from about the time of Applicant's 
priority date. 

1. T. Howes and M. Smith, LDAP: Programming Directory Enabled Applications with 
Lightweight Directory Access Protocol. Macmillan Technology Series, 1997. In addition to the 
cover and publication pages, Applicant provides herewith an excerpt at pages 4-5. See Appendix 
A to this Amendment C. In the excerpt, in the section entitled "What a Directory Service is 
Not," it is clearly stated that a directory services is not a general purpose database. While this 
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entire section is provided in Appendix A, Applicant would like to draw the Examiner's attention 
to one particular paragraph: 

The first thing you should not do is treat the directory like a general database. It's not 
designed with that kind of use in mind, and you'll likely be disappointed with the results. 
This means the directory is not suited to provide transaction-based service, cannot 
generally handle huge numbers of updates, and usually would make a bad engine for an 
SQL application. 

2. United States Patent No. 6,016,499, assigned on its face to Novell, Inc. The filing date of 
the priority provisional application is February 20, 1997, and the filing date of the non- 
provisional application is July 21, 1997. At col. 1, line 60 et seq, for example, the applicant 
distinguishes between "directory services" and "relational databases." 

Unlike relational databases, "directory service" structures are a relatively recent 
development in information technology. The need for directory services became clear 
only after computer networks became a prominent part of the information landscape and 
grew so large and complex that their administration required full-time attention from 
specialists. Directory services are sometimes referred to as "naming services." 

A variety of directory service providers are now available to help administer both the 
location of network resources and the rights of network users to use those resources. 
Many, but not all, directory service tools conform at least in part with the X.500 directory 
services standard. One well-known directory service system includes NetWare Directory 
Services software commercially available from Novell, Inc. of Provo, Utah (NETWARE 
DIRECTORY SERVICES is a trademark of Novell, Inc.). As used herein, "Novell 
Directory Services" ("NDS") includes NetWare Directory Services and any other 
directory service commercially available from Novell, Inc. 

In contexts other than the present one, a directory services repository is sometimes called 
a directory services "database." Both repositories and databases may be distributed, 
because that is mainly a matter of storage and locks for enforcing consistency, rather than 
a question of the basic internal structure. But "database" and "repository" are not 
interchangeable in the present context. 

A repository supports naming services. Each repository is organized hierarchically, as 
one or more trees. Each object in a tree (except the root object) has exactly one parent. 
Objects may generally have children, which may inherit properties from their ancestor 
objects. Objects are instances of "classes," as described in detail below. 

By contrast, "database" as used herein refers to a relational database. A given database 
may support any of a wide variety of commercial or personal activities. Each database is 
organized as a set of tables in which rows represent records and columns represent record 
fields. Certain fields may be found in multiple tables, and the values of these "key" or 
"index" fields are used to guide database searches. Database access and manipulation 
involve combining information from various tables into new combinations to obtain 
different views of the data. 
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In short, databases and repositories arose at different times to meet different needs, and 
have different structures and capabilities. There is no need to dwell further here on the 
details of relational database structure, SQL, or ODBC, as numerous references on those 
topics are widely available. Many computer science professionals have also taken at least 
one course in databases. 

3. The SLAPD and SLURPD Administrator's Guide, University of Michigan, 30 April 
1996, Release 3.3. In addition to the cover, publication pages and Table of Contents, Applicant 
provides herewith an excerpt at pages 1-10. See Appendix B to this Amendment C. In the 
excerpt, in the section entitled "1.1 What is a directory service?" it is discussed how a directory 
service differs from a database. The entire section 1.1 (two paragraphs only), is reproduced 
below: 

1.1 What is a directory service? 

A directory is like a database, but tends to contain more descriptive, attribute-based 
information. The information in a directory is generally read much more often than it is 
written. As a consequence, directories don't usually implement the complicated 
transaction or roll-back schemes regular databases use for doing high-volume complex 
updates. Directory updates are typically simple all-or-nothing changes, if they are 
allowed at all. Directories are tuned to give quick-response to high- volume lookup or 
search operations. They may have the ability to replicate information widely in order to 
increase availability and reliability, while reducing response time. When directory 
information is replicated, temporary inconsistencies between the replicas may be OK, as 
long as they get in sync eventually. 

There are many different ways to provide a directory service. Different methods allow 
different kinds of information to be stored in the directory, place different requirements 
on how that information can be referenced, queried and updated, how it is protected from 
unauthorized access, etc. Some directory services are local, providing service to a 
restricted context (e.g., the finger service on a single machine). Other services are global, 
providing service to a much broader context (e.g., the entire Internet). Global services are 
usually distributed, meaning that the data they contain is spread across many machines, 
all of which cooperate to provide the directory service. Typically a global service defines 
a uniform namespace which gives the same view of the data no matter where you are in 
relation to the data itself. 

Applicant has thus amply demonstrated that the Krishnaswamy "database" does not 
anticipate the "enterprise directory" recited in the claims. Since the Examiner's contention 
regarding the Examiner's contention regarding the Krishnaswamy "database" anticipating the 
"enterprise directory" pervades all the prior art based rejections, it is respectfully submitted that 
all of the prior art based rejections should be withdrawn. 
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CONCLUSION 



Applicants' believe that all pending claims are allowable and respectfully request a 
Notice of Allowance for this application from the Examiner. Should the Examiner believe that a 
telephone conference would expedite the prosecution of this application, the undersigned can be 
reached at the telephone number set out below. 

Respectfully submitted, 
BEYER WEAVER LLP 
/ASH/ 

Alan S. Hodes 
Reg. No. 38,185 

P.O. Box 70250 
Oakland, CA 94612-0250 
408-255-8001 
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Copyright 



Copyright © 1992-1996 Regents of the University of Michigan. All Rights 
Reserved. 

Redistribution and use in source and binary forms are permitted provided that this 
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warranty. 
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1. Introduction to slapd and slurpd 



This document describes how to build, configure, and run the stand-alone LDAP 
daemon (slapd) and the stand-alone LDAP update replication daemon (slurpd). It is 
intended for newcomers and experienced administrators alike. This section provides 
a basic introduction to directory service, and the directory service provided by slapd 
in particular. 

1.1 What is a directory service? 

A directory is like a database, but tends to contain more descriptive, attribute-based 
information. The information in a directory is generally read much more often than 
it is written. As a consequence, directories don't usually implement the complicated 
transaction or roll-back schemes regular databases use for doing high-volume 
complex updates. Directory updates are typically simple all-or-nothing changes, if 
they are allowed at all. Directories are tuned to give quick-response to high-volume 
lookup or search operations. They may have the ability to replicate information 
widely in order to increase availability and reliability, while reducing response time. 
When directory information is replicated, temporary inconsistencies between the 
replicas may be OK, as long as they get in sync eventually. 

There are many different ways to provide a directory service. Different methods 
allow different kinds of information to be stored in the directory, place different 
requirements on how that information can be referenced, queried and updated, how 
it is protected from unauthorized access, etc. Some directory services are local, 
providing service to a restricted context (e.g., the finger service on a single 
machine). Other services are global, providing service to a much broader context 
(e.g., the entire Internet). Global services are usually distributed, meaning that the 
data they contain is spread across many machines, all of which cooperate to provide 
the directory service. Typically a global service defines a uniform namespace which 
gives the same view of the data no matter where you are in relation to the data itself. 

1.2 What is LDAP? 

Slapds model for directory service is based on a global directory model called 
LDAP, which stands for the Lightweight Directory Access Protocol. LDAP is a 
directory service protocol that runs over TCP/IP. The nitty-gritty details of LDAP 
are defined in RFC 1777 "The Lightweight Directory Access Protocol." This 
section gives an overview of LDAP from a user's perspective. 

What kind of information can be stored in the directory? The LDAP directory 
service model is based on entries. An entry is a collection of attributes that has a 
name, called a distinguished name (DN). The DN is used to refer to the entry 
unambiguously. Each of the entry's attributes has a type and one or more values. 
The types are typically mnemonic strings, like "cn" for common name, or "mail" 
for email address. The values depend on what type of attribute it is. For example, a 
mail attribute might contain the value "babs@umich.edu". A jpegPhoto 
attribute would contain a photograph in binary JPEG/JFIF format. 

How is the information arranged? In LDAP, directory entries are arranged in a 
hierarchical tree-like structure that reflects political, geographic and/or 
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organizational boundaries. Entries representing countries appear at the top of the 
tree. Below them are entries representing states or national organizations. Below 
them might be entries representing people, organizational units, printers, 
documents, or just about anything else you can think of. Figure 1 shows an 
example LDAP directory tree, which should help make things clear. 



c=GB 



c=US 



o=U of M 



cn=Barbara J Jensen 



cn: Babs Jensen 
cn: Barbara Jensen 
mail: babs@umich.edu 



o=Acme. Inc. 



mail: info@acme.com 
fax: 313 123-4567 



Figure 1: An example LDAP directory tree. 

In addition, LDAP allows you to control which attributes are required and allowed 
in an entry through the use of a special attribute called objectclass. The values 
of the ob jectclass attribute determine the schema rules the entry must obey. 

How is the information referenced? An entry is referenced by its distinguished 
name, which is constructed by taking the name of the entry itself (called the relative 
distinguished name, or RDN) and concatenating the names of its ancestor entries. 
For example, the entry for Barbara Jensen in the example above has an RDN of 
"cn=Barbara J Jensen" and a DN of "cn=Barbara J Jensen, o=U 
of M, c=US". The full DN format is described in RFC 1779, "A String 
Representation of Distinguished Names." 



How is the information accessed? LDAP defines operations for interrogating and 
updating the directory. Operations are provided for adding and deleting an entry 
from the directory, changing an existing entry, and changing the name of an entry. 
Most of the time, though, LDAP is used to search for information in the directory. 
The LDAP search operation allows some portion of the directory to be searched for 
entries that match some criteria specified by a search filter. Information can be 
requested from each entry that matches the criteria. 

For example, you might want to search the entire directory subtree below the 
University of Michigan for people with the name Barbara Jensen, retrieving the 
email address of each entry found. LDAP lets you do this easily. Or you might 
want to search the entries directly below the c=US entry for organizations with the 
string "Acme" in their name, and that have a fax number. LDAP lets you do this 
too. The next section describes in more detail what you can do with LDAP and how 
it might be useful to you. 

How is the information protected from unauthorized access? Some directory 
services provide no protection, allowing anyone to see the information. LDAP 
provides a method for a client to authenticate, or prove its identity to a directory 
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server, paving the way for rich access control to protect the information the server 
contains. 

1.3 How does LDAP work? 

LDAP directory service is based on a client-server model. One or more LDAP 
servers contain the data making up the LDAP directory tree. An LDAP client 
connects to an LDAP server and asks it a question. The server responds with the 
answer, or with a pointer to where the client can get more information (typically, 
another LDAP server). No matter which LDAP server a client connects to, it sees 
the same view of the directory; a name presented to one LDAP server references the 
same entry it would at another LDAP server. This is an important feature of a global 
directory service, like LDAP. 

1.4 What is slapd and what can it do? 

Slapd is an LDAP directory server that runs on many different UNIX platforms. 
You can use it to provide a directory service of your very own. Your directory can 
contain pretty much anything you want to put in it. You can connect it to the global 
LDAP directory service, or run a service all by yourself. Some of slapd's more 
interesting features and capabilities include: 

Choice of databases: Slapd comes with three different backend databases you 
can choose from. They are LDBM, a high-performance disk-based database; 
SHELL, a database interface to arbitrary UNIX commands or shell scripts; and 
PASSWD, a simple password file database. 

Multiple database instances: Slapd can be configured to serve multiple 
databases at the same time. This means that a single slapd server can respond to 
requests for many logically different portions of the LDAP tree, using the same or 
different backend databases. 

Generic database API: If you require even more customization, slapd lets you 
write your own backend database easily. Slapd consists of two distinct parts: a 
front end that handles protocol communication with LDAP clients; and a backend 
that handles database operations. Because these two pieces communicate via a well- 
defined C API, you can write your own customized database backend to slapd. 

Access control: Slapd provides a rich and powerful access control facility, 
allowing you to control access to the information in your database(s). You can 
control access to entries based on LDAP authentication information, IP address, 
domain name and other criteria. 

Threads: Slapd is threaded for high performance. A single multi-threaded slapd 
process handles all incoming requests, reducing the amount of system overhead 
required. Slapd will automatically select the best thread support for your platform. 

Replication: Slapd can be configured to maintain replica copies of its database. 
This master/slave replication scheme is vital in high-volume environments where a 
single slapd just doesn't provide the necessary availability or reliability. 
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Configuration: Slapd is highly configurable through a single configuration file 
which allows you to change just about everything you'd ever want to change. 
Configuration options have reasonable defaults, making your job much easier. 

Slapd also has its limitations, of course. It does not currently handle aliases, which 
are part of the LDAP model. The main LDBM database backend does not handle 
range queries or negation queries very well. These features and more will be 
coming in a future release. 

7.5 What about X.500? 

LDAP was originally developed as a front end to X.500, the OSI directory service. 
X.500 defines the Directory Access Protocol (DAP) for clients to use when 
contacting directory servers. DAP is a heavyweight protocol that runs over a full 
OSI stack and requires a significant amount of computing resources to run. LDAP 
runs directly over TCP and provides most of the functionality of DAP at a much 
lower cost. 

This use of LDAP makes it easy to access the X.500 directory, but still requires a 
full X.500 service to make data available to the many LDAP clients being 
developed. As with full X.500 DAP clients, a full X.500 server is no small piece of 
software to run. 

The stand-alone LDAP daemon, or slapd, is meant to remove much of the burden 
from the server side just as LDAP itself removed much of the burden from clients. 
If you are already running an X.500 service and you want to continue to do so, you 
can probably stop reading this guide, which is all about running LDAP via slapd, 
without running X.500. If you are not running X.500, want to stop running 
X.500, or have no immediate plans to run X.500, read on. 

It is possible to replicate data from a slapd directory server to an X.500 DSA, 
which allows your organization to make your data available as part of the global 
X.500 directory service on a "read-only" basis. This is discussed in section 11.6. 

Another way to make data in a slapd server available to the X.500 community 
would be by using a X.500 DAP to LDAP gateway. At this time, no such software 
has been written (to the best of our knowledge), but hopefully some group will see 
fit towrite such a gateway. 

1.6 What is slurpd and what can it do? 

Slurpd is a UNIX daemon that helps slapd provide replicated service. It is 
responsible for distributing changes made to the master slapd database out to the 
various s lap d replicas. It frees slap d from having to worry that some replicas might 
be down or unreachable when a change comes through; slurpd handles retrying 
failed requests automatically. Slapd and slurpd communicate through a simple text 
file that is used to log changes. 
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